fix(seer): Read sentry_run_id instead of the deprecated run_id#1224
Open
trevor-e wants to merge 5 commits into
Open
fix(seer): Read sentry_run_id instead of the deprecated run_id#1224trevor-e wants to merge 5 commits into
trevor-e wants to merge 5 commits into
Conversation
The autofix API is migrating run identifiers from a legacy numeric run_id to a UUID sentry_run_id, and will eventually drop run_id entirely. The CLI was reading run_id directly off autofix state and forwarding it to the continue-run endpoint, which would silently break once the numeric field disappears. Add getAutofixRunId() to prefer sentry_run_id (falling back to run_id for older responses), and use it everywhere the CLI reads a run identifier. The continue-run request now sends the ID under whichever body field matches its type — sentry_run_id (UUID field) or run_id (integer field) — since the server validates them as distinct, differently-typed fields and a UUID under run_id would be rejected. Verified against the live API: GET/POST responses return both fields as documented, and a real continue-run POST with a UUID sentry_run_id returns 202. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
|
Contributor
Codecov Results 📊✅ Patch coverage is 85.71%. Project has 5333 uncovered lines. Files with missing lines (1)
Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
+ Coverage 81.81% 81.83% +0.02%
==========================================
Files 423 423 —
Lines 29343 29348 +5
Branches 19118 19124 +6
==========================================
+ Hits 24006 24015 +9
- Misses 5337 5333 -4
- Partials 1989 1987 -2Generated by Codecov Action |
getAutofixRunId returned undefined when neither run_id nor sentry_run_id was present, and issue plan's buildPlanData let that flow straight into the CLI's JSON output as run_id: undefined. The API dual-writes both fields on every non-null autofix state, so a missing run ID there is a malformed response, not a legitimate in-progress state — it shouldn't be passed through silently. Renamed to requireAutofixRunId and made it throw, so both call sites (the plan output and the continue-run request) treat a missing run ID as the same invariant violation instead of one silently swallowing it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
triggerRootCauseAnalysis only ever kicks off a brand-new run, so sentry_run_id can't be null for the legacy-run reason that applies to the GET/continue-run paths. Drop the misleading claim. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cut prose that restated what the code/types already say, keeping only the parts that explain non-obvious server behavior (why run_id vs sentry_run_id must go under different body keys, why a missing run ID means malformed state). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The comment claimed sentry_run_id is always present, but it's null for legacy runs too — the real guarantee is that at least one of the two fields is present. Also drop the 'check the issue in Sentry web UI' hint from the error: this only fires on a malformed API response, and there's nothing to see in the web UI that explains a missing run ID. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The autofix API is migrating run identifiers from a legacy numeric
run_idto a UUIDsentry_run_id, and the numeric field is slated for eventual removal. The CLI readrun_iddirectly off autofix state and forwarded it when continuing a run, which would silently break once that field disappears from responses.Added
requireAutofixRunId()to prefersentry_run_id, falling back torun_idfor older responses, and used it everywhere the CLI reads a run identifier (issue plan's output and its continue-run call). The API dual-writes both fields on every non-null autofix state, so a missing run ID is a malformed response, not a legitimate in-progress state — the helper throws in that case rather than lettingundefinedflow into the CLI's JSON output.The continue-run request sends the ID under whichever body field matches its type:
sentry_run_id(a UUID field) orrun_id(an integer field). The server validates these as two distinct, differently-typed fields, so a UUID sent underrun_idwould be rejected outright.Verified against the live API: GET/POST responses return both fields as expected (int
run_id, UUIDsentry_run_id), and a real continue-run POST with a UUID undersentry_run_idreturns 202.